Mobile stations require a lot of information about the capabilities of the used network and the called or calling party. Usually this information is available at the call setup signalling. However, this is not always the case. When information is missing, service and bearer level compatibility may not be reached at the call setup and the call fails. This problem is described in the following in more detail.
Mobile networks can support either a multinumbering scheme or a single numbering scheme (SNS) or both (ref. to 3GPP TS 29.007). Commercial networks started with multinumbering scheme in the beginning of the GSM era, but several operators have later introduced the single numbering scheme despite the below mentioned (and solved) problem with the scheme.
In the multinumbering scheme the user has a separate MSISDN number for each service that is used in a mobile terminated call. Service information is stored per each MSISDN number in the home location register (HLR) or home subscriber server (HSS). The information is used in a mobile terminated call setup when no unambiguous service information is received from the calling party in the incoming setup request. Ref. to 3GPP TS 29.007.
In the single numbering scheme the user has only one MSISDN number common to all services. When no unambiguous service information is received from the calling party in the incoming setup request, the network sends the setup without a service definition to the mobile station (MS). The MS shall determine the service to be used in the call. There is a risk that the mobile network or the intermediate network(s) or the calling party cannot support the service or the channel configuration indicated by the MS (ref. to 3GPP TS 27.001, version 4.1.0).
Thus, when the MS responds with a service definition (e.g. a multislot/HSCSD channel configuration) that cannot be supported by the network, the call will fail. Consequently, to be on the safe side, the basic 9.6 kbit/s service should always be used to guarantee a successful call. However, 9.6 kbit/s is too slow for many applications.
Alternatively, the MS may respond with the same data rate. However, the MS does not know whether the ITC (Information Transfer Capability) in the original call setup is UDI/RDI or 3.1 kHz or speech. Consequently, even if the data rate itself is correct, the call may fail because the other party may use e.g. a modem and the other e.g. a UDI/RDI protocol.
Thus, summarising, the invention relates to the problem of ambiguous service information receiving setup request. In such cases, the network sends the setup without a service definition to the mobile station (MS). The MS shall determine the service to be used in the call. However, there is a risk that the mobile network or the intermediate network(s) or the calling party cannot support the service or the channel configuration indicated by the MS.
In the above, problems related to mobile terminated call were described. However, similar problems also occur for the mobile originated case, as is described in the following.
For example, when a user is roaming in a visited network, the user does not know the capabilities of the visited network and is thus unable to configure the MS to make a successful data call to a home intranet. (A well educated user would make a few trials with different settings, but even this nuisance can be avoided with the method proposed in this report). Hence, in this case the user can either try to use the service he wishes to use and to hope that this service is supported, or he can set up a basic service call with a data rate of, e.g., 9.6 kBit/s.
Both approaches are disadvantageous, since in the first alternative, the call may fail, and in the second alternative, the full performance of the MS cannot be utilised. Hence, the present situation is not acceptable.